home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19990422-19990725 / 000103_news@watsun.cc.columbia.edu _Wed May 26 17:52:53 1999.msg < prev    next >
Internet Message Format  |  2020-01-01  |  3KB
  1. Return-Path: <news@watsun.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id RAA29573
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Wed, 26 May 1999 17:52:52 -0400 (EDT)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id RAA01302
  7.     for kermit.misc@watsun.cc.columbia.edu; Wed, 26 May 1999 17:32:40 -0400 (EDT)
  8. X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
  9. From: jrd@cc.usu.edu (Joe Doupnik)
  10. Subject: Re: kermit process hangs around after terminal disconnect
  11. Message-ID: <eYzrHu7mxevb@cc.usu.edu>
  12. Date: 26 May 99 15:27:46 MDT
  13. Organization: Utah State University
  14. To: kermit.misc@watsun.cc.columbia.edu
  15.  
  16. In article <7ihl1n$asf$1@nnrp1.deja.com>, Mr. Scott <scott_davis@my-deja.com> writes:
  17. >>From the standpoint of the Unix side of the connection everything is
  18. >>perfectly fine.  It has not received any data in a long time but there
  19. >>is no requirement that it ever receive any data.  Nor has it tried to
  20. >>send any data therefore as far as it is concerned everything
  21. >>is ok
  22. > 
  23. > Hmmm, perhaps I had better study the TCP protocol better.
  24. > I thought it was the nature of the TCP protocol to maintain
  25. > a "connected" state through the (invisible to the socket programmer)
  26. > use of some sort of "keepalive" packets.  If the keepalive packets
  27. > don't arrive after a time, the connection is deemed lost.  That was my
  28. > impression.  So although no application data is needed or expected in
  29. > either direction, the lack of keepalive messages should still flag the
  30. > telnetd that the connection is no longer active and therefore notify
  31. > the terminal driver to cleanup the session.  Again, that is only my
  32. > impression of how it works.  Do you have anything to add?
  33. --------------
  34.     Unfortunately or not, TCP has no such facility. The keepalive
  35. I discussed today is a special feature on some systems that cuts in after
  36. say an hour of inactivity. There is normally no traffic when the apps
  37. have nothing to say, and it is a common misunderstanding that network
  38. connections are like telephone connections (where hanging up breaks
  39. an electrical circuit).
  40.     As Jeff tried to explain, what happens after a stack tries to
  41. send and fails is up to that operating system to manage. The stack is
  42. often in the kernel and failure messages are passed up to the application.
  43. What happens next is up to the application, not up to the protocol stack.
  44. Thus they may be ignored up there and programs continue to be active.
  45. Some systems have an overriding inactivity timer, a looong one, which
  46. works on any connection in the manner that no activity will kill the
  47. login process and any available descendents. Many don't have this facility.
  48. Some, say VMS, snoop and notice the communications channel has declared
  49. a no-comms situation and shortly after will kill the login session. But
  50. it takes outgoing traffic to detect this event.
  51.     Joe D.